Flexible Transactions

A very central part of Bitcoin is the transaction. Everything you do in Bitcoin will essentially use or depend on Bitcoin transactions.

In the original Bitcoin 0.1 release Satoshi Nakamoto included a design that is a very good indication of his intentions for the future. He included a version field for transactions. This means that we can cleanly upgrade the transaction format by creating a new version. People can then choose on creation if they want to use the new or the old format.

How would an upgrade work? See the Upgrade Guide.

The old format has run out of place to add new features, it has accumulated lots of not very clean hacks to make it continue working. New features can not be added in any safe way. It is time to look for a new format that we can use for decades to come.

Flexible Transactions is that format, it has the version number '4' and it has been designed and programmed in Bitcoin Classic by Tom Zander. It solves a long list of problems that have eluded solution for years and it has been designed with future growth in mind. Flexible Transactions allows future upgrades to be done in a much clearer and controlled fashion making this stepping stone for cleaner and faster development which will hold your coins value safe.

Flexible Transactions is still under developement and can not be used on main-net yet. However, it is feature complete and being tested. Bitcoin Classic is the main client with support included in version 1.2 and later.

There are two flags you can pass on the command-line to enable it; --testnet-ft switches the client to a testnet mode, specifically one that is for testing flexible transactions. If you need some coin, send an email to Tom with a testnet-ft bitcoin address.

Additionally there is the -flextrans option that explicitly enables v4 transactions parsing, relaying etc. You don't want to use this option on the main chain, but using it on the regtest testing chain is perfectly fine.

When you enabled FlexTrans, you will notice that the RPC command createrawtransaction will allow you to pass the transaction version and it will return a FlexTrans encoded transaction if you pass version 4. Similarly, the signrawtransaction will support signing of those transactions.

Bitcoin issues fixed by Flexible Transactions

• Malleability (more)
• Linear scaling of signature checking (more)
• Hardware wallet support (proofs) (more)
• Very flexible future extensibility
• Double Spend Proofs
• Makes transactions smaller
• Supports the Lightning Network
• Support future Scripting version increase

Background

Flexible Transactions is maybe best explained by watching this video where Tom explains the technology in a simple way for all audiences.

Additionally useful may be the FlexTrans-vs-SegWit page.

We describe how FlexTrans would affect different users when it will be rolled out on the Upgrade Guide.

Test application

For users and developers that want to parse the relatively abstract binary datastream which make up bitcoin transactions there is a good test application that Bitcoin Classic made available for free to github

This application allows you to;

• read any transaction and print its contents.
• convert any transaction into the FlexTrans markup so you can test parsers.
• read FlexTrans transactions and print warnings encountered during parsing.

The application depends on QtCore being available on the system it is being compiled on.

Language Bindings

The parsing of the transaction is really not that hard, and made really easy with the language bindings which are available in the cmf-bindings git repository. The general approach is that there is a MessageParser and a MessageBuilder class. If you want to create a transaction you use the MessageBuilder and you add all the individual components using a very simple API.

There currently are language bindings for

• C
• C#
• C++
• C++ without boost, but uses Qt
• Java
• Python (both version 2 and 3 work)

Specification

Flexible Transactions is a schema based on the Compact Message Format low level binary serialization.

The CMF system is based on name/format/value tokens which are encoded with the aim to have the smallest resulting files.

The specification for CMF can be found here.

The specification for FlexTrans can be found here

Additionally, the proposal to the Bitcoin community has been made in the form of a BIP. Which can be found here.